DESCRIPTION
  This is a dynamic loader for Sun3 and Sun4.  The interface is very
  simple.  There are three main functions:

    setArg0(const char *)  - Call with argv[0] to find main object file
    bool loadFile(const char *fileName) - Load an object file
    long value(const char *sym, int bad=-1) - Find symbol value

  This loader reads the object file into memory and does the relocation
  on its own.  This makes it fast and it works even if the main object
  file is dynamically linked (the loaded object file can make calls into
  the shared libraries).  

  The advantages of this loader over SunOS 4.1 dlopen() or "ld -A":
    1) Works with normal object files (does not use shared libraries)
    2) Works if the main object file is dynamically linked.
    3) Loaded object can have symbol dependencies into main file or
       previously loaded object files.
    4) It is much faster than the "ld -A" approach.
  The disadvantages:
    1) It will not load every type of file since I have not found ways
       of making all relocation types in Sun object files.
  Other things to note:
    1) It is written in C++.
    2) It is free and unsupported (although I would like to hear of bugs).

HISTORY
  This is the second release of my dynamic loader for Sun3/4 C++ OS 4.0.

I have tested this on Sun3/280 OS 4.0.3 and Sun4/260 OS 4.0.3.

This is as-is software.  You hook it up to your heart-lung machine and
you may be sorry, but I won't be responsible.

I can be reached at

  Glenn Gribble			glenn@synaptics.com	uunet!synaptx!glenn
  Synaptics, Inc.		(408) 434-0110
  2860 Zanker Road, Suite 105	(408) 434-9819 FAX
  San Jose, CA 95134

Some general notes:

HOW TO INSTALL THE LOADER

This loader will work on a Sun3 and Sun4.  To make the test programs, just
unshar this shar file and type make.

After the make, type 'loadtest' to run the test program.  The test program
loads 'sub.o' and prints out a few messages.  Read 'loadtest.cxx' for more
info.

PSEUDO MAN PAGES

NAME
  loader - A dynamic loader
SYNOPSIS
  #include "loader.h"

  void setArg0(const char *arg0);

  bool loadFile(const char *dot_oh_file);

  long value(const char *sym, int bad=-1);

DESCRIPTION
  setArg0() must be called with argv[0] so that the loader can find the
  executable file associated with this program (the loader needs the
  symbols in this file).  setArg0() uses the value of the enviroment
  variable PATH to find what file the program probably came from.

  loadFile() loads an object file into memory and calls the constructors
  of that file.  The first time loadFile is called, it initialize the
  dynamic load enviroment by loading the symbols for the running program,
  loading the symbols for the shared libraries, and finding the location
  of the shared libraries in memory.

  value() returns the value of a symbol.  For instance to find the location
  of a function "myFunc" in memory, do this (watch out for C++ name mangling):
    long v = value("myFunc",-1);
    if (v == -1)
      printf("myFunc not found\n");
    else
      printf("myFunc is %x\n", v);
  Note that the value of a symbol may change after a new file is loadFile()d,
  because this file may re-define any symbol.


NAME
  error - formatted error message printing

SYNOPSIS
  #include "loader.h"

  void error(const char *fmt ...);
  void warn(const char *fmt ...);
  void info(const char *fmt ...);

DESCRIPTION
  Print out formatted error/warning/informational messages.  These routines
  can be replaced with more complex routines that print out input file names
  or whatever.


LOADER THEORY OF OPERATION
  First, the main object file is located by looking for it on the path.
  (This is what setArg0() does.)

  The first time loadFile() is called the shared libraries are located
  using information contained in __DYNAMIC and their symbol tables are
  loaded into memory.  The symbol table for the main program is loaded
  into memory after the shared libraries.  The reverse order is necessary
  because a stack of symbols is built up.  During lookup, a symbol is
  first looked up in the loaded object files (most recently loaded first),
  then the main program, and finally the shared libraries.

  At this point, the loader is ready to load an object file.

  The text and data segments of the object file are loaded into memory
  and space for the bss segment is allocated just after the data segment.
  The symbol table is loaded.  Finally the relocation segments are loaded
  and relocation is performed.  After relocation, the relocation segments
  are unloaded as they are no longer needed.  The symbol table is retained.

  Finally, any symbols that look like the symbols for file-level
  constructors (start with "___sti__") are evaluated and the associated
  function called.


WHAT'S WRONG WITH THIS PICTURE? (or things to do)
  The loader can not cope with certain kinds of relocations.  It should
  be changed to support these other kinds, but so far I have not found
  one in any of my files so I am not sure what the other kinds mean.

  Symbol table searching is done linearly at each level in the stack
  of symbol tables.  This could be done in a more intelligent fashion,
  but it has not been a real speed problem.  It might be a problem if
  many symbol lookups were being performed.